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ABSTRACT 


The  field  of  control  systems  has  witnessed  an  explosion  in  state-space  tech¬ 
niques  addressing  a  variety  of  critical  design  issues  facing  control  engineers  today. 
Modern  computational  tools,  such  as  the  MATRIX^-  Product  Family  developed  by 
Integrated  Systems  Incorporated,  allow  the  designer  to  quickly  design,  test  and  imple¬ 
ment  control  systems  based  on  these  state— space  techniques.  These  new  computing 
advances  shorten  the  time  required  to  complete  a  control  design  from  a  few  years 
to  a  few  months.  However,  as  the  design  process  progressed  new  inputs  and  ouputs 
were  required,  which  usually  resulted  in  a  confusing  mess  of  connections  that  were 
hard  to  follow.  Therefore,  a  universal  system  was  needed  that  could  be  used  on  any 
controller  design  to  aid  in  the  imderstanding  and  tracking  of  the  controller’s  inputs 
and  outputs.  A  desription  of  this  system  is  given  along  with  a  detailed  step  by  step 
process  on  how  it  was  implemented  on  an  Unmanned  Air  Vehicle  (UAV). 
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I.  INTRODUCTION 

The  field  of  control  systems  has  witnessed  an  explosion  in  state-space  tech¬ 
niques  developed  to  address  a  variety  of  critical  design  issues.  These  techniques 
include  'H21  Hoo,  h,  feedback  linearization  theory,  and  Linear  Matrix  Inequalities  to 
name  a  few.  To  assess  their  usefulness,  some  of  these  techniques  have  been  applied 
to  real-life  problems  with  some  success.  Nevertheless,  despite  all  this  effort,  the  user 
community  remains  skeptical  of  the  utility  of  modern  control  techniques.  This  is 
particularly  true  in  the  aerospace  community,  where  most  of  the  control  systems  in 
service  today  were  developed  using  classical  control  design  techniques. 

At  the  Naval  Postgraduate  School  we  were  fortunate  to  have  obtained  several 
unmanned  aircraft  from  various  agencies  for  testing  purposes.  Therefore,  a  goal  was 
set  to  design  and  flight  test  controllers  developed  with  the  aid  of  modern  control  tools. 
Early  in  our  research  we  realized  that  a  completely  integrated  hardware/software 
system  was  needed.  This  system  would  allow  us  to: 

•  Build  and  analyze  controllers  using  a  high  level  development  tool 

•  Automatically  generate  computer  code  once  a  satisfactory  controller  has  been 

obtained 

•  Download  the  code  into  a  hardware  system  capable  of  flying  the  aircraft. 

We  have  been  able  to  develop  such  a  system  using  the  MATRIXj^Product 
Family  of  rapid  prototyping  software  available  from  Integrated  Systems  Incorporated 
(ISI)  [Ref.  1].  This  software  incorporates  a  program  called  RealSim  that  uses  a 
Graphical  User  Interface  (GUI)  to  step  the  engineer  through  the  design  process.  This 
rapid  prototyping  process  greatly  reduces  the  time  required  to  design,  test  and  imple¬ 
ment  a  controller  when  compared  with  the  conventional  design  process.  A  comparison 
of  these  two  techniques,  conventional  vs.  rapid  prototyping  is  given  next. 
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A.  CONVENTIONAL  DESIGN 

Conventional  design  of  control  systems  takes  place  in  several  stages,  using 
several  different  tools  for  control  design,  software  engineering,  data  acquisition,  and 
testing.  A  typical  procedure  for  tlie  design  process  is: 

•  The  engineer  creates  an  accurate  plant  model. 

•  The  model  is  simulated  to  see  how  it  compares  with  reality.  Data  measuring 
the  behavior  is  collected,  and  the  model  is  changed,  if  necessary. 

•  An  engineer  builds  a  control  system  for  the  plant.  The  control  system,  includ¬ 
ing  the  plant,  is  tested. 

•  The  model  is  implemented  in  hardware  and  tested.  Modifications  are  made, 
if  necessary. 

•  After  more  testing,  a  functional  prototype  is  obtained. 

This  method  of  design  has  two  major  shortcomings: 

•  It  is  expensive,  because  the  prototype  or  the  controller  must  be  modified  at 
each  stage. 

•  It  is  very  time-consuming  from  conception  to  finished  prototype. 

B.  RAPID  PROTOTYPING 

In  contrast,  the  rapid  prototyping  design  process  uses  one  tool  and  two  steps 
to: 

•  Integrate  the  tools  for  each  stage  of  the  system  development  into  a  single 
environment. 

•  Allow  the  design  progress  to  easily  flow  through  the  development  stages. 

•  Create  a  working  prototype  early  in  the  design  process. 

A  flow  diagram  comparing  the  conventional  and  rapid  prototyping  techniques 
is  given  in  Figure  1  [Ref.  1]. 
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TradltiofMd  prototypirg:  Many  sequential  steps,  many  tools 
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Prolotj^tog  with  the  RealSlra:  Two  steps,  one  tool 


Figure  1.  The  Rapid  Prototyping  Concept  [Ref.  1] 

This  thesis  describes  how  the  rapid  prototyping  software  RealSim  was  used  to 
develop  a  universal  system  that  can  be  used  for  any  controller  design.  This  system 
was  used  to  design  a  controller  using  synthesis  which  was  then  tested  on  an 
Unmanned  Air  Vehicle  (UAV)  called  Bluebird. 

Bluebird  was  donated  to  the  Unmanned  Air  Vehicle  Lab  by  the  Naval  Ocean 
System  Center,  San  Diego.  It  has  a  12.5  foot  wingspan,  a  25  pound  payload  capability, 
and  is  equipped  with  a  full  avionics  suite,  including  IMU,  GPS  and  air  data  sensors. 
It  is  controlled  through  the  use  of  a  RF  link  that  sends  a  Pulse  Width  Modulated 
(PWM)  signal  that  drives  the  aircraft’s  actuators.  One  of  these  links  was  modified 


3 


II.  EQUATIONS  OF  MOTION  & 
CONTROLLER  DESIGN 


Before  discussing  the  specifics  of  the  uniform  system  development,  we  present 
the  Equations  of  Motion  (EOM)  and  the  WooController  designed  for  Bluebird,  since 
these  were  used  to  test  the  utility  of  the  system. 

First,  we  introduce  the  following  notation  suggested  by  [Ref.  2]: 

P  -  position  of  the  origin  of  {B}  expressed  in  {/}; 

V  =  (u,  u,  w)'  -linear  velocity  of  the  origin  of  {B}  relative  to  {/},  expressed 

in  {B}; 

A  =  {<j),  0,  il>y  -  vector  of  Euler  angles  which  describe  the  orientation  of  frame 

{B}  with  respect  to  {/} 

^  =(^5  -  angular  velocity  of  {B}  relative  to  {/},  expressed  in  {B}; 

=  b7?.(A)  -  rotation  matrix  from  {B}  to  {/}. 

Q  =  Q(A)  -  matrix  that  relates  ^A  to  H  and  satisfies  the  relationships  4 A  = 

QQ  and  Q(0)  =  7; 

G  -  vector  of  gravitational  acceleration  expressed  in  {/}.  We  assume  a  constant 

gravitational  field. 

Furthermore,  let  U  denote  the  vector  of  control  inputs  acting  on  the  vehicle.  For 
Bluebird,  U  consists  of  elevator  el,  thrust  th,  ailerons  ail  and  rudder  r. 

Let  {W}  denote  a  wind  axis.  It  is  usually  attached  to  the  aircraft’s  center 
of  gravity  and  is  defined  using  the  right  hand  rule,  with  the  x-axis  pointing  in  the 
direction  of  the  apparent  wind.  For  example,  in  the  absence  of  wind  the  aircraft’s 
inertial  velocity  resolved  in  {W}  has  the  following  form:  [\\V\\  0  0]'.  Now  let  ^11 
denote  the  transformation  from  {W}  to  {B}.  Notice,  can  be  computed  using  the 
angle  of  attack  a  and  the  sideslip  angle  /3,  where  /?  =  sin"^  |j^  and  a  =  sin“^  n^. 
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Now,  using  the  above  notation,  the  Bluebird  dynamics  have  the  following  form: 

'  iy  =:fv{VAA)  +  iv(v,n)H(v,n,u), 

,  +  Ja(v,n)n(v,n,u), 

y  =  \  ( 

iP  “i-KV, 


(11.1) 


I A  =sn, 


where 


Qo  0  Cd^ 

FY(v,a,A)  =  -s(a)v+^v.G  +  ^i,\\vf4,ii\  +  o  c,,  o 


0 


0  Crf,  0 


+  Cj/p  0  Cj,,.  n  ► , 

0  c/„  0 


Cd,i  0  0 


MVAA)  =  ^p\\vf^n  0  0  c,.„  ,  w(yn,f/)  =  £/ 

a,  0  0 


s6  0  0 


0  0 


ru{V,9.,k)  =  JE^l-S{il)XB^+^p\\Vf  0  sc  0  U„0  +  0 


0  0  s6 


%  0  Clr 

+  0  Cro.  0 


0  Cnr  ^  0 


0  0 


0  ^ 


0  0  <^ail 


Xn(V’,  n,  A)  —  J'j5^-/)||y|ps^7^  Ctoj;,  Cjn^i  0  0 

0  0  Cuail  ^rtid 


0  0 
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s  :=  wing  reference  area 
p  :=  air  density 

c  :=  wing  mean  chord 

m  :=  mass 

Jb  :=  aircraft’s  inertia  tensor  resolved  in  {B} 
p  :=  air  density 

b  :=  wing  span 

d,  y,  I  :=  normalized  drag,  lateral  force  and  lift 

1,  m,  n  :=  normalized  roll  pitch  and  yaw  moments 

CxQ  :=  normalized  nominal  force  or  moment  coefficient 

Cxy  ’=  stability  derivative: 

Uc  :=  a:-component  of  vehicle'strimair speed. 

Notice,  in  equations  (II.l)  we  did  not  include  p  dynamics. 

The  set  of  trimming  trajectories  £  for  Bluebird  is  defined  as  follows: 

Vc 

Ac  =  Qc 

Ac  J  I  (11.2) 

JV(i4,i^c,Ac)  +  iv{Vc,nc)n{Vc,cia,Uc)  =  0 
+  Myc,^c)niVa,(lc,Uo)=0, 
where  Vc,  fic  S’Hd  Ac  can  be  computed  using  the  desired  airspeed  desired  flight 
path  angle  7c  and  the  desired  turning  rate  rpc-  Now,  given  [utc  7c  i’cY  and  /9c  =  0  we 
can  solve  for  Vc,  fie,  Uc  and  Ac: 

rv{Va,nc,kc)  +  2v(v'c,ftc)7i(v^,nc,£^c)  =  o 
:^n(T4,nc,Ac)  +  Xn(Fc,nc)H(Fc,flc,17c)  =  0 
Qc^^c  —  Ac  =  0 
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7c -[0  1  0]  ar5r(^7^f7^)  =  0, 


(11.3) 


where  Vc  =  [«c  Vc  and  the  arg  function  extract  the  angles  X  from  the  rotation 
matrix  %{X):  X  —  arg{lZ{X))  (for  example,  for  straight  line  flight  the  last  expression 
in  equations  (II.3)  reduces  to  -  oic)-  Equations  (IL3)  consist  of  12  equations 

in  12  unknowns,  since  the  trimming  value  of  the  heading  angle  ^  is  arbitrary  and  can 
be  solved  using  analytical  or  numerical  methods.  For  an  example  of  an  interesting 
analytic  solution  see  [Ref.  3,  4]. 

Using  the  solution  to  equations  (II.3)  the  linear  model  for  Bluebird  was  ob¬ 
tained  along  a  straight  line  trajectory  characterized  by  the  velocity  Vc  of  73  fps,  7c 
of  zero  and  wings  level  {ipc  =  0)  (a  typical  cruise  condition  for  Bluebird).  This  model 
was  used  to  design  a  linear  feedback  controller  for  the  vehicle. 

A.  FEEDBACK  CONTROLLER  DESIGN 

1.  Open  Loop  Analysis 

The  linear  model  of  Bluebird  in  cruise  is  typical  for  a  fixed  wing  aircraft, 
i.e.  it  naturally  decouples  into  lateral  and  longitudinal  dynamics.  The  longitudinal 
dynamics  are  characterized  by  a  short  period  mode  with  a  natural  frequency  of  .5 
radians/second,  a  damping  ratio  of  .7  and  a  lightly  damped,  stable  phugoid  mode. 
Lateral  dynamics  include  a  lightly  damped  dutch  roll  mode  with  a  damping  ratio  of 
.03,  a  roll  mode,  and  an  unstable  spiral  mode  [Ref.  9].  Bluebird  utilizes  standard 
elevators,  rudder,  and  differential  ailerons  for  control  and  a  single  gas  engine  driven 
propeller  in  the  nose  for  thrust. 

To  ensure  appropriate  dutch  roll  response  the  RC  pilot’s  flight  technique  of 
tying  positive  rudder  and  negative  aileron  together  was  mimicked. 

2.  Design  Requirements 

The  basic  control  strategy  for  the  feedback  controller  is  to  emulate  the  ap¬ 
proach  used  by  the  RC  pilot.  Classically,  the  pilot  uses  elevator  and  thrust  to  control 
altitude  and  airspeed  in  steady  state.  These  considerations  motivate  the  following 


8 


design  requirements  for  the  feedback  controller. 


1.  Zero  Steady  State  Error 

•  Achieve  zero  steady  state  tracking  errors  in  airspeed,  altitude  and  bank 
angle  commands  in  the  presence  of  constant  and  light  variable  winds. 

2.  Bandwidth  Requirements 

•  The  command-loop  bandwidth  for  each  command  channel  should  be  no 
greater  than  1  radian  per  second  and  no  less  than  1/10  radian  per  second. 

•  The  control-loop  bandwidth  should  not  exceed  12  radians  per  second  for 
the  elevator,  aileron  and  rudder  loops,  and  5  radians  per  second  for  the 
throttle  loop.  These  numbers  represent  50  %  of  the  corresponding  actuator 
bandwidths  and  shall  ensure  the  actuators  are  not  driven  beyond  their 
linear  operating  range. 

3.  Closed  Loop  Damping  and  Stability  Margins 

•  The  dominant  closed  loop  eigenvalues  should  have  a  damping  ratio  of  at 
least  0.5.  Simultaneous  gain  and  phase  margins  of  6db  and  45  deg  in  each 
control  loop  must  be  achieved. 

3.  Linear  Design:  Hoo  Synthesis 

The  methodology  selected  for  linear  control  system  design  was  T-too  synthesis 
[Ref.  6].  This  method  rests  on  a  firm  theoretical  basis,  and  leads  naturally  to  an 
interpretation  of  control  design  specifications  in  the  frequency  domain.  Furthermore, 
it  provides  clear  guidelines  for  the  design  of  controllers  to  achieve  robust  performance 
in  the  presence  of  plant  uncertainty.  The  basic  steps  in  the  controller- design  proce¬ 
dure,  including  the  development  of  the  synthesis  model,  were  done  using  the  approach 
described  in  [Ref.  7].  This  approach  provides  an  intuitive  and  straightforward  way 
for  converting  the  design  requirements  into  the  weights  for  the  TfooSynthesis  model. 
Consider  Figure  3.  Here  Ci  is  the  controller  to  be  designed,  and  Qi  is  the  linear  model 
of  Bluebird. 

In  Figure  3  the  vector  of  exogenous  inputs  w  represents  the  commanded  inputs. 
The  vector  yi  represents  vehicle’s  airspeed,  altitude  and  bank  angle.  The  regulated 
output  z  includes  the  outputs  of  the  weighting  matrices  Wi  and  W2.  These  matrices 
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Figure  3.  Synthesis  and  Analysis  Model 


had  the  following  form: 


0  0 

Wi  =  0  f  0 

0  0^ 

5 

C4  0  0 

W2=  0  C5  0  , 

0  0  C6 

where  the  constants  Ci,i  =  1,6  were  used  as  the  design  knobs  adjusted  to  meet  the 
closed  loop  tracking,  damping,  control  and  command  loop  bandwidth  requirements. 
Notice  that  the  structure  of  Wx  ensures  the  steady  state  tracking  of  constant  com¬ 
mands  in  all  three  channels.  The  resulting  linear  controller  has  the  following  form: 


=  8z  8<j>]'  —  8zc  8^^' 


=  Ccx8X,  +  V^x[8V'  8rt'  8A'Y, 


where  Vt  —  ||V||,  the  TiooState  feedback  gain  is  /C  =  [Cd  I^ci]  a-nd  SXc  represents  the 
state  of  the  integral  errors.  The  feedback  system  consisting  of  the  linear  plant  Qi  and 
the  controller  Ci  was  found  to  meet  all  the  design  specifications  given  in  Section  2. 

Since  the  effectiveness  of  the  aerodynamic  control  surfaces  (these  include  ele¬ 
vator,  rudder  and  ailerons)  is  proportional  to  the  dynamic  pressure  q  =  0.5/3||y|p  the 
controller  Ci  was  gain-scheduled  on  q: 

SE  =  Sz  8<j>]'  —  {8vt^  8zc  8(f>^' 

isx,  =SE 

SU  =  diag(|,  l){C,iSX,  +  Va [SV  SQ' 
where  qo  represents  the  nominal  value  of  q. 

4.  Implementation  of  the  Linear  Controller 

Using  the  V  technique  for  implementing  the  gain-scheduled  controllers  [Ref.  5] 
the  family  of  linear  gain-scheduled  controllers  Ci(^q)  was  implemented  on  the  nonlinear 
plant  Q  as  follows: 

E  =[vt-Vt^  z-  Zc  ^c] 

C  :=  lx,  ==f{C,a,  +  V,,liV'  in'  |A]'} 

U  =x„ 

\ 

where  the  differentiation  operator  ^  was  replaced  by  a  causal  operator  with  the 
transfer  function  [Ref.  5]. 
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III.  HARDWARE/SOFTWARE 
DESCRIPTION 


A.  BACKGROUND 

The  primaxy  tool  for  the  research  conducted  in  the  Avionics  lab  is  the  hard¬ 
ware/software  interface  provided  by  the  MATRIX^-  Product  Family  developed  by 
Integrated  Systems  Inc  (ISI).  This  tool  set  greatly  enhances  the  control  engineer’s 
ability  to  test  and  evaluate  a  design  concept.  The  primary  software,  called  Realsim, 
consists  of  an  easy  to  use  graphical  user  interface  (GUI)  that  can  be  run  on  either  a 
workstation  or  PC.  The  interface  interacts  with  a  high  speed  digital  signal  processing 
board  developed  by  Texas  Instruments,  called  the  C30,  that  uses  parallel  process¬ 
ing  techniques  to  handle  many  tasks  simultaneously.  One  of  the  unique  features  of 
this  software  is  the  ability  to  automatically  program  higher-language  code  such  as  C 
or  ADA  for  the  designed  controller.  This  greatly  reduces  the  time  required  for  the 
designer  to  test,  modify  and  implement  a  designed  controller. 

B.  HARDWARE 

The  hardware  system  in  the  avionics  lab  consists  of  two  ISA  bus  PC  adapter 
boards,  which  can  be  placed  in  any  IBM  compatible  PC  with  an  ISA  bus  architecture 
and  available  ISA  slots.  One  of  the  boards  is  installed  in  a  luggable  PC  called  AClOO 
and  the  second  is  installed  on  the  Pentirun  tower  PC  called  America.  America  is  per¬ 
manently  connected  to  the  AA  department  network,  while  ACIOO  can  be  connected  to 
the  network  via  a  TCP/IP  connection.  Using  this  TCP/IP  connection  these  comput¬ 
ers  can  communicate  with  the  Realsim  software  installed  on  the  UNIX  workstations. 
This  software  can  be  run  on  any  Sun  workstation  in  the  AA  department. 

The  two  hardware  boards  included  in  the  PC  portion  of  the  Realsim  Series 
AC-100  Model  C30  system  are  the  following:  a  board  which  acts  as  a  motherboard  for 
the  C30  digital  signal  processor  (DSP),  and  a  “DSPJFLEX”  board,  which  can  hold 
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up  to  4  “IP”  modules.  The  “IP”  modules  are  compact  input/output  (I/O)  devices 
that  perform  a  particular  type  of  I/O.  The  PC  America  has  4  IP  modules,  consisting 
of  one  serial  communications  (IP_Serial)  module,  one  Digital  to  Analog  (IPJDAC), 
and  two  Pulse  Width  Modulation  (IP .68332)  modules.  The  luggable  PC  AClOO  has 
3  IP  modules,  consisting  of  one  serial  communications  (IPJSerial)  module,  one,one 
Digital  to  Analog  (IPJDAC)  and  one  Pulse  Width  Modulation  (IP  .68332)  module. 
The  two  boards  are  connected  by  a  seperate  comm  bus  via  a  ribbon  cable.  The  I/O 
configuration  for  AClOO  and  America  are  given  in  Table  I.  These  values  are  needed 
when  connecting  the  hardware  to  the  software  using  the  Hardware  Connection  Editor 
(HCE),  which  will  be  explained  later  in  the  thesis. 

1*  IP -Serial  Module 

The  IPJSerial  module  provides  two  channels  of  high  performance  multi-mode 
serial  communications  with  RS-232-C  and  RS-422  capability.  The  module  can  be 
programmed  to  baud  rates  of  2  Mbit /sec  supporting  both  asynchronous  and  syn¬ 
chronous  protocols.  The  PC  AClOO  has  two  serial  modules  labelled  1  and  2.  As 
stated  in  Table  I  each  of  these  modules  has  two  channels  and  they  are  defined  as 
channels  A  and  B.  To  create  a  connection  from  a  SystemBuild  model  to  the  IPJSerial 
module,  the  Hardware  Connection  Editor  (HCE)  must  be  used.  -For  the  specifics  on 
this  procedure  please  see  [Ref.  1]. 


Table  I.  I/O  Configuration 


Module 

America 

AClOO 

IPJSerial  1 

- 

- 

IPJSerial  2 

3 

3 

IPJIiADC 

1 

- 

IPJDAC 

2 

2 

IP.68322 

4 

4 
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2.  IPJiiADC  Module 

The  HiADC  module  provides  16  input  analog  channels  with  12-bit  resolution 
and  synchronous  sampling  of  all  inputs.  The  module  can  convert  one  analog  channel 
in  1.2  fisec  or  approximately  800  K  samples/second.  Conversion  of  all  16  channels 
takes  approximately  20  fisec.  Each  channel  has  a  fixed  voltage  range  of  ±  5V  with 
an  input  impedance  of  1  MOhm.  There  is  no  anti-aliasing  filtering  provided  on  the 
HiADC  module  so  inputs  should  be  band— limited  to  1  /2  the  sampling  frequency  of 
the  system.  To  create  a  connection  from  a  SystemBuild  model  to  the  IPJIiADC 
module,  the  HCE  must  be  used.  For  the  specifics  on  this  procedure  please  see  [Ref. 
!]• 

3.  IP_DAC  Module 

The  IPJDAC  module  provides  six  channels  of  12-bit  digital  to  analog  conver¬ 
sion.  Each  channel  may  be  configured  to  either  ±5V  or  O-IOV  output  ranges.  To 
create  a  connection  from  a  SystemBuild  model  to  the  IPJDAC  module,  the  HCE  must 
be  used.  For  the  specifics  on  this  procedure  please  see  [Ref.  1]. 

4.  IP_68332  Module 

The  IP_68322  module  is  a  time  processing  unit  produced  by  Motorola,  that 
can  perform  one  or  more  hardware  I/O  functions. 

The  software  drivers  for  each  of  the  IP  modules  are  located  in  the  C30-SP 
subdirectory  under  the  ACIOODSP  directory.  These  drivers  will  be  merged  into  the 
input  and  output  fields  in  the  c_c30.hce  file,  which  is  used  by  the  Hardware  Connection 
Editor  (HCE)  to  determine  the  allowable  I/O  devices.  A  copy  of  the  c_c30.hce  file 
must  be  in  the  working  directory  of  the  project  of  interest  to  ensure  the  targeted 
hardware  configuration  is  used. 

C.  SOFTWARE 

The  Realsim  software  installed  on  the  UNIX  workstations  gives  the  controls 
engineer  a  vast  array  of  tools  that  make  the  designing  and  testing  of  a  control  system 
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much  quicker  and  simpler  than  before.  Through  the  use  of  a  GUI  (see  Figure  4) 
the  designer  can  follow  a  flow  diagram  that  steps  the  user  through  the  various  soft¬ 
ware  components  to  fully  implement  a  given  design.  These  software  tools  consists 
of  Xmath/  SystemBuild,  Autocode,  Interactive  Animation  (lA)  Builder,  Hardware 
Connection  Editor  (HCE),  and  two  utilities  that  compile,  link,  download  and  run  the 
control  design.  A  brief  description  of  these  applications  is  given  next. 


1  Heeds 
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Figure  4.  Realsim  Graphical  User  Interface  (GUI) 


!♦  Xmath/SystemBuild 

Xmath/SystemBuild  is  a  software  program  similar  to  the  Matlab/Simulink 
software  program  developed  by  Math  Works  Inc.  Xmath/Systembuild  was  designed 
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to  include  an  extensive  set  of  design  and  analysis  functions  for  botk  the  classi¬ 
cal  mput/output  control  techniques  and  the  modern  state-space  control  techniques. 
Specifics  on  how  to  design  and  analyze  a  model  can  be  found  in  the  Xmath  and 
SystemBuild  Core  Manuals.  The  key  requirement  to  test  a  model  with  external 
mputs/outputs,  and  to  eventually  Autocode  the  model,  is  to  have  the  external  in¬ 
puts/outputs  in  the  highest  level  Superblock  of  the  model. 

The  SystemBuild  program  uses  a  hierarchical  method  of  organization,  based 
on  the  SuperBlock  concept.  SuperBlocks  provide  a  way  of  organizing  a  group  of  blocks 
that  define  a  function  into  a  compact  form  for  display  and  understanding,  for  example 
“Sensor  CalibrationJ)isplay”  or  “Control_Block”.  Through  the  use  of  this  hierarchy, 
variable  names  can  be  passed  up  and  down  the  hierarchical  structure  allowing  the 
engineer  to  easily  track  and  understand  what  variables  are  and  where  they  interact 
with  the  model.  A  diagram  showing  the  interaction  of  Xmath  and  SystemBuild  is 
given  in  Figure  5. 

Once  the  model  is  drawn  and  labeled,  there  are  several  ways  to  test  it.  It  can 
be  tested  within  Xmath/SysyemBuild  using  the  “SIM”  function  (see  Core  Manuals) 
or  by  generating  realtime  code.  The  second  method,  generating  realtime  code,  is 
the  preferred  method  since  it  allows  for  the  gerenation  of  a  higher-level  language  to 
conduct  hardware-in-the-loop  testing.  To  generate  real  time  code  the  user  just  uses 
a  pull  down  menu  on  the  SystemBuild  GUI  and  selects  “Generate  Real  Time  Code”. 
This  produces  a  file  with  the  models  name  followed  by  a  .rtf  extension.  This  Real 
Time  Code  is  a  top  level  Input/Output  code  that  is  used  by  the  AutoCode  program 
to  produce  a  higher-level  code  such  as  C. 

2.  Autocode 

An  integral  part  of  the  quick  design  and  testing  of  a  controller  is  the  ability 
to  generate  high-level  code  such  as  C  or  ADA  automatically.  AutoCode  has  this 
capability,  and  generates  optimized  code  from  a  library  of  standard  functions  and 
calls.  The  Realsim  package  in  the  Avionics  lab  currently  has  a  C  code  module. 
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Figure  5.  Xmatli/SystemBuild  Integration  [Ref.  1] 

To  generate  C  code  two  tasks  must  be  accomplished: 

•  Ensure  settings  in  target_config.cfg  are  correct. 

•  Click  on  the  AutoCode  icon  on  main  GUI. 

The  target_config.cfg  file  is  created  by  using  the  Realsim  utility  retarget. 
This  utility  can  be  run  at  the  command  prompt  in  the  working  directory  or  by  clicking 
on  the  Retarget  icon  on  the  utilities  menu.  This  procedure  will  ask  several  questions. 
First  it  will  ask  for  the  computer’s  host  name,  which  will  be  either  AC  100  or  America. 
This  host  name  designates  the  computer  on  the  network  where  the  application  will  be 
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compiled,  downloaded  and  executed.  For  the  rest  of  the  questions  the  default  setting 
should  be  accepted  by  hitting  return. 

Once  the  two  above  steps  are  completed  a  new  file  with  a  .c  extension  will 
be  created  in  the  working  directory.  This  file  will  be  used  later  to  compile,  link, 
download  and  run  the  design. 

3.  Interactive  Animation  Editor  (lA) 

This  program  is  used  to  build  a  graphical  animation  module  to  display  desired 
system  outputs  in  various  forms  during  testing.  The  animation  diagrams  are  made  by 
a  drag  and  drop  process  from  a  given  library  of  predrawn  gauges,  strip  charts,  dials, 
switches,  and  other  various  input  and  output  devices.  If  a  specific  dial  or  gauge  for 
the  user  needs  can’t  be  found  in  the  library,  custom  pictures  can  also  be  created.  The 
“RTF  Names”  button  loads  the  I/O  names  from  the  model  .rtf  file,  to  help  associate 
given  inputs  and  outputs  to  their  display  icons.  A  RTF  file  must  be  loaded  prior 
to  making  any  connections.  Using  a  connection  editor  similar  to  the  one  used  in 
SystemBuild  the  appropriate  inputs  and  outputs  are  connected  to  the  appropriate 
devices. 

Once  a  picture  is  completed  the  user  selects  “Save  Picture”  and  a  file  with  a 
.pic  extension  is  created  in  the  working  directory.  This  file  will  be  used  later  in  the 
Hardware  Connection  Editor  (HCE)  and  link  process.  Note:  If  the  SystemBuild  I/O 
is  changed,  the  I/A  Editor  must  be  run  again  and  connections  changed  to  reflect  the 
changes  to  the  model.  A  sample  lA  picture  is  shown  in  Figure  6. 

4.  Hcirdware  Connection  Editor  (HCE) 

The  hardware  connection  editor  is  used  to  associate  external  inputs  and  out¬ 
puts  in  the  SystemBuild  model  with  either  external  I/O  devices  or  the  I/A  module. 
This  is  accomplished  using  two  screens  that  have  the  same  basic  layout.  The  first 
screen  is  for  SuperBlock  external  inputs  and  the  second  for  external  outputs,  (see 
Figure  7). 
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Figure  6.  Sample  of  Interactive  Animation  Picture 


The  HCE  reads  the  external  inputs/outputs  from  the  .rtf  file  with  the  same 
name  as  the  current  target.  The  HCE  automatically  checks  to  see  if  a  local  copy  of 
the  c_c30.hce  is  present,  and  if  so  reads  it.  If  not,  it  reads  one  out  of  the  default 
AClOO  directory.  This  file  informs  the  HCE  what  type  of  external  I/O  devices  are 
present  in  the  target  AClOO  computer,  and  the  HCE  will  only  allow  these  device 
types  to  be  selected.  A  detailed  explanation  of  the  columns  on  the  screens  and  their 
uses  can  be  found  in  [Ref.  1]. 
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Figure  7.  Sample  of  Hardware  Connection  Editor 


5.  Compile  and  Link 

Once  tEe  desired  inputs  and  outputs  are  connected  the  design  needs  to  be 
complied  and  linked  to  the  C30.  The  Realsim  software  will  attempt  to  connect  via 
ftp  with  the  AC  100  target  computer.  For  the  PC  America  the  user  must  first  type 
aclOOsvr  at  the  DOS  prompt  to  enable  the  computer  for  ftp  transfer.  For  the 
portable  PC  A(7100  the  user  repeats  this  same  command,  or  if  Windows  is  running, 
double  clicks  on  aclOO  terminal”.  Once  the  connection  is  made,  the  C  source  files 
required  will  be  transferred  to  the  target  computer  for  remote  compiling  and  linking. 
The  compilier  generates  object  code  from  the  .c  file,  and  the  link  creates  a  C30  DSP 
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executable  from  the  object  code. 

If  there  are  other  C  files  required  for  the  project  for  compiling  and  linking, 
there  should  also  be  a  file  in  the  working  directory  named  “sa_user.cmd”.  In  this 
file,  for  each  C  file  to  be  included,  there  should  be  a  line  that  says  COMPILE 
^filename^  .c  and  a  line  that  says  LINKW^ITH  <Cfilenanie^  ,  where  filename 
is  the  source  file  name  to  be  included,  without  extension.  This  only  applies  to  C 
source  files.  If  there  are  header  files  referred  to  in  the  C  source  files,  they  must  be 
manually  copied  to  the  project  directory  on  the  AClOO  computer  using  ftp.  If  there 
is  more  than  one  file  included,  and  there  are  dependencies  in  one  file  from  another 
(i.e.  function  calls  to  functions  defined  in  another  source  file),  they  should  be  listed 
in  sa_user.cmd  in  the  order  of  dependency. 

6.  Download  and  Run 

When  this  program  is  selected  on  the  GUI,  Realsim  software  wilh  attempt  to 
connect  to  the  target  AClOO  computer  through  ftp.  Once  the  connection  is  made, 
it  will  load  the  C30  executable  into  the  C30  memory  and  prepare  it  to  run.  It  will 
bring  up  the  lA  module  on  the  workstation  screen,  and  place  a  control  panel  called 
lA  Client,  with  6  buttons  below  the  lA  module.  See  Figure  8. 


Figure  8.  lA  Client  Control  Window 

The  first  button,  START  CONTROLLER  ,  will  start  the  model  if  the 
model  has  just  been  loaded  and  not  run  yet.  It  will  stop  the  model  if  it  is  currently 
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running,  and  it  will  restart  the  model  if  it  has  been  previously  stopped.  The  second 
button,  HARDWARE  RESET  ,  will  cause  the  Realsim  controller  to  immediately 
reset  and  causes  lA  Client  to  exit.  This  is  the  best  way  to  exit  after  a  run,  as  it  will 
clear  the  C30  memory  and  return  the  AClOO  computer  to  a  ready  status.  The  third 
button,  EXIT  GRAPHICS  ,  exits  lA  Client  without  rebooting  the  controller.  This 
is  a  software  reboot  only,  which  stops  the  model  and  terminates  the  ftp  connection. 
This  button  is  not  recommended  for  use,  as  it  will  not  stop  the  model  from  running 
on  C30.  K  download  and  run  is  selected  again  by  the  original  client  which  started  the 
model,  it  will  ask  if  you  wish  to  reconnect  the  model.  If  a  different  client  attempts  to 
log  on  to  run  the  same  or  a  different  model  it  will  ask  if  the  current  model  should  first 
be  terminated.  Therfore,  it  is  always  best  to  terminate  the  model  by  pressing  the  first 
button.  The  fourth  button,  START  DATA  ACQUISITION  ,  starts/stops  data 
acquisition.  Data  acquisition  should  always  be  stopped  before  rebooting  the  C30,  or 
the  acquired  data  will  not  be  saved  to  a  file.  The  last  button  allows  you  to  set  certain 
data  acquisition  parameters.  The  Scale  Frequency  button  in  the  upper  right  corner 
allows  the  user  to  slow  down  or  speed  up  the  animation. 

In  addition  to  the  six  main  buttons  on  the  Realsim  GUI,  there  are  additional 
features  that  can  be  invoked  from  the  menu  located  in  the  upper  right  corner  of  the 
RealSim  GUI.  These  utilities  are  hidden  when  Realsim  is  first  started  but  can  be 
displayed  by  clicking  on  the  Show  Utilities  button.  These  utilities  give  the  user 
the  ability  to  accomplish  such  tasks  as  data  collection,  conversion  of  data  for  use  in 
Xmath,  lA  Client,  and  numerous  other  features.  More  information  can  be  found  in 
[Ref.  1]. 
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IV.  RAPID  PROTOTYPING  SYSTEM 

(RPS) 


A.  RPS  ARCHITECTURE 

In  order  to  conduct  flight  test  a  Rapid  Prototyping  System  (RPS)  was  devel¬ 
oped  with  the  following  features: 

•  synthesis,  analysis  and  simulation  of  flight  management  algorithms  using  a 
high  level  developmental  tool. 

•  automatic  generation  of  computer  code  once  a  satisfactory  flight  management 
system  has  been  obtained. 

•  code  download  into  a  hardware  system  capable  of  flying  a  UAV. 

•  display  and  collection  of  appropriate  flight  data. 

A  diagram  of  the  RPS  architecture  is  given  in  Figure  9. 

The  hardware  architecture  is  divided  into  the  following  two  major  components: 
a  ground  station  and  an  unmanned  aircraft. 

1.  Ground  Station 

The  ground  station  handles  all  the  flight  management  functions  and  data  col¬ 
lection.  It  consists  of  the  following  three  components: 

•  Sparc  II  Workstation:  this  computer  contains  the  software  package  RealSim 
that  is  used  to  design,  code,  and  implement  a  control  algorithm. 

•  Luggable  PC.  this  computer  contains  the  TI  C30  digital  processor,  and  the 
DSPJFLEX  board  that  holds  the  IP_Modules  explained  in  Chapter  II. 

•  Communications  Box:  this  box  houses  various  devices  used  to  communicate 
with  the  unmanned  aircraft. 

The  devices  that  are  used  for  communication  with  the  aircraft  are  the  fol¬ 
lowing:  two  DGR-115  spread  spectrum  RF  modems  from  Freewave  Inc.,  capable  of 
transmission  rates  of  116  Kbaud  at  20  miles,  which  are  used  to  transmit  and  receive 
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Unmanned  Aircraft 


Ground  Station 


Figure  9.  RPS  Hardware  Architecture 

telemetry  information,  a  Futaba  pulse  control  modulated  (PCM)  transmitter  which 
was  modifed  to  give  the  computer  the  ability  to  control  the  aircraft,  and  a  PVT-6 
differential  GPS  (DPGS)  receiver  from  Motorola. 

The  Sun  workstation  is  connected  to  the  luggable  PC  by  a  standard  TCP/IP 
connection.  The  luggable  PC  is  connected  to  the  communications  box  by  four  ribbon 
cables  from  the  four  IP_modules. 

2.  Unmanned  Aircraft 

The  unmanned  aircraft  is  equipped  with  a  complete  avionics  suite  that  is  nec¬ 
essary  for  autonomous  flight.  The  avionics  suite  consists  of  the  following  components: 
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an  Inertial  Measurement  Unit  (IMU)  from  Watson  Inc.,  air  data  sensors,  and  a  PVT- 
6  DGPS  receiver.  The  data  from  these  devices  are  transmitted  to  the  ground  station 
via  two  additional  spread  spectrum  RF  Hnks  from  Freewave  Inc.  The  aircraft  also 
has  a  PCM  receiver  that  is  used  to  drive  the  actuators  on  the  control  surfaces  and 
throttle.  An  important  feature  of  this  avionics  suite  is  its  portability;  it  can  be  easily 
duplicated  or  moved  to  a  dilferent  platform. 

B.  FLIGHT  TEST 

Flight  tests  were  conducted  using  the  UAV  Bluebird  at  an  outlying  field  near 
the  Naval  Postgraduate  School.  These  tests  involved  transporting  the  Sun  Sparc  2 
workstation  Intrepid,  the  luggable  PC  AClOO,  the  communication  box,  the  RF  an¬ 
tenna,  the  portable  generator,  and  Bluebird  to  the  field.  To  connect  these  components 
the  following  steps  should  be  accomplished: 

•  Ensure  aU  computer  coimections  are  made  (i.e.  external  hard  drive,  monitor 
etc.) 

•  Make  all  power  connections  to  the  portable  generator. 

•  Connect  TCP/IP  cable  from  Sun  to  luggable  PC. 

•  Connect  the  four  IP  .module  ribbon  cables  to  the  communication  box.  Both 
the  ribbon  cables  and  the  box  axe  label  to  ensure  proper  match-up. 

•  Connect  the  RF  antenna  cable  to  communication  box. 

Once  all  the  connections  are  made  the  system  should  be  booted  up.  Once 
the  Sun  finishes  its  boot  up  sequence  it  will  ask  for  a  user  ID  and  password.  Once 
the  system  is  running  change  to  the  working  directory,  which  is  /mnt/home/  archy- 
tas/realsim/baseline/flight_test_current.  This  is  the  latest  version  of  the  test  setup. 
Start  the  RealSim  software  by  typing  <  realsim  >  at  the  command  prompt,  this 
will  bring  up  the  RealSim  GUI  mentioned  earlier.  See  Figure  10. 
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Figure  10.  RealSim  GUI 


This  GUI  is  slightly  different  than  the  one  depicted  in  Figure  4  because  the 
system  has  been  updated  and  the  black  lines  connecting  the  software  components  are 
now  gray.  To  initiate  a  flight  test  complete  the  following  two  steps: 


•  On  AClOO  type  <C  aclOOsur  This  initiates  the  ftp  program  on  AClOO. 

•  Click  on  the  download  and  run  button  on  the  RealSim  GUI. 


Once  the  download  and  run  button  has  been  pressed  the  generated  C  code  is 
downloaded  to  the  C30  DSP  chip.  After  reaching  the  DSP  chip  the  code  starts  to 
run  and  service  the  IP -modules  loaded  on  the  DSP-Flex  board  via  the  ribbon  cable. 
The  code  also  controls  the  animation  screens  via  a  TCP/IP  connection  to  the  Sun 
workstation. 

The  sytem  will  now  display  the  following  2  screens,  (see  Figures  11,  12).  The 
Master  page  allows  the  tester  to  scroll  through  a  series  of  Interactive  Animation 
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Screens  that  were  developed  using  the  Interactive  Animation  software  explained  in 
Chapter  11.  By  using  the  left  mouse  button  and  clicking  on  a  displayed  icon  the 
system  will  transfer  to  that  lA  screen.  This  allows  the  test  engineer  to  accomplish 
such  tasks  as  conducting  calibrations,  monitoring  the  IMU,  GPS  data,  or  viewing 
flight  parameters  during  the  test  process.  These  screens  are  tied  to  the  inputs  and 
ouputs  in  the  SystemBuild  diagrams.  When  inputs  are  entered  on  these  screens  the 
data  is  incorporated  in  the  running  model  and  calibration  equations  located  in  the 
SystemBuild  diagrams.  Below  this  picture  is  the  iaclient  window  that  starts/stops 
the  model.  Next  the  steps  necessary  to  conduct  an  actual  flight  test  will  be  outlined. 


MASTBR 


Figure  11.  Master  Flight  Test  lA  Screen 


C.  CALIBRATIONS 

Before  any  flight  test  can  be  conducted,  it  is  necessary  to  calibrate  the  ac¬ 
tuators  and  sensors  on  Bluebird  to  ensure  accurate  data  transfer.  The  calibration 
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procedure  consists  of  taking  various  measurements  from  the  following  sources:  actua¬ 
tor  pots,  command  receiver,  and  command  transmitter,  then  comparing  this  data  to 
ensure  the  same  values  are  being  recorded. 

This  procedure  is  accomplished  by  entering  data  into  various  windows  of  the 
four  lA  screens:  Cal  Actuators,  Cal  Com  Rec,  Calibrate  DAC,  and  Cal  Air  Data. 
The  data  that  is  entered  is  assigned  to  variables  that  are  associated  with  equations 
located  in  the  SystemBuild  diagrams.  The  various  SystemBuild  diagrams  and  a 
complete  description  of  their  use  is  given  in  Chapter  V.  The  following  subsections 
will  descibe  in  detail  the  use  of  the  four  lA  screens. 

1.  Cal  Actuators 

This  screen  calibrates  the  actuators  on  Bluebird.  The  flow  of  variables  for  the 
actuator  calibration  is  outlined  in  Figure  13.  First  the  voltages  from  the  actuators 
are  measured,  passed  through  the  IMU,  and  transmitted  down  to  the  grormd  station 
via  the  RF  links.  The  data  variables  are:  wordlJmu,  word2Jmu,  wordSJmu  and 
word4imu.  These  four  variables  contain  each  actuator’s  position  in  volts.  These 
variables  are  input  into  block  2  of  the  AJ) JMU  superblock  (see  Figure  33)  which 
converts  them  to  degrees.  The  trim  values  are  then  added  to  these  variables,  which 
give  the  degrees  of  actuator  deflection  for  the  chosen  flight  condition.  The  variables 
that  are  associated  with  this  screen  are  given  in  Table  II. 


30 


Figure  13.  Variable  Flow  for  Actuator  Calibration 

The  first  four  variables  are  connected  in  the  A_D  JMU  Superblock  to  block 
number  97,  which  is  a  summer.  The  remaining  four  variables  are  outputs  from  the 
A JD  JMU  Superblock  and  are  displayed  on  the  four  dials.  See  Figure  14. 

In  order  to  calibrate  the  aircraft’s  actuators  a  zero  had  to  be  defined.  This 
is  an  arbitrary  location  for  the  actuator  position  and  was  decided  to  be  a  cruise 
condition  of  70  kts  at  1000  ft.  The  RC  pilot  flew  the  aircraft  in  this  flight  condition 
and  obtained  trim  settings.  These  trim  settings  were  then  read  off  the  actuator  pots 


Table  II.  Actuator  Calibration  Screen  Variables 


VariableName 

V  ariableNumber 

elevjservo-trim 

238 

rudjservoJrim 

239 

ail-servo_trim 

240 

trt_servo_trim 

241 

elevjservo«deg 

301 

rud-servo_deg 

302 

ail_servo_deg 

303 

trt^ervo-deg 

304 
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Figure  14.  Actuators  Calibration  Screen 


and  were  converted  to  degrees  for  the  three  control  surfaces  and  percent  rpm  for  the 
throttle.  This  data  is  given  in  Table  III.  This  data  should  be  entered  into  the  Elev, 
Rud,  Ail,  and  Trt  Trim  boxes.  See  Figure  14.  This  data  is  for  Bluebird  only,  and 
would  have  to  be  recalculated  for  another  aircraft  or  a  different  flight  condition.  Once 
the  user  has  entered  the  data  the  Return  button  should  be  pressed  to  return  to  the 
previous  screen. 

2.  Cal  Com  Rec 

This  screen  calibrates  the  command  receiver.  The  flow  of  variables  for  this 
calibration  is  given  in  Figure  15. 
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Table  III.  Actuator  Calibration  Data 


J 


Same 

value 


Figure  15.  Variable  Flow  for  Command  Recevier  Calibration 

A  picture  of  the  Calibrate  Command  Receiver  screen  is  given  in  Figure  16. 

There  are  numerous  variables  associated  with  this  screen  and  they  are  listed  in 
Chapter  V  under  the  ConomandJTx  superblock.  The  calibration  of  the  three  control 
surfaces  are  similar,  so  only  the  steps  for  the  elevator  will  be  explained  in  detail.  To 
calibrate  the  other  two  surfaces  the  user  must  repeat  the  same  steps.  The  calibration 
of  the  throttle  is  slightly  different,  so  it  will  also  be  explained. 

First,  the  joystick  for  the  elevator  on  the  commajid  receiver  is  moved  until  the 
number  under  the  ServoJmu  column  is  reading  -5.  The  variable  associated  with 
this  column  is,  elevjservo_deg,  which  comes  from  the  A JD  JMU  superblock.  The  value 
displayed  in  the  PW (usee)  column  is  read  off  and  entered  into  the  el_pwm_back5 
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Figure  16.  Calibrate  Command  Receiver  Screen 


box  in  the  next  column.  This  value  represents  the  pulse  width  in  fisec  of  the  PWM 
signal  coming  from  the  receiver  and  is  read  through  the  PWM  IP_module.  The  value 
is  assigned  the  variable  name  tp7  and  is  input  4  in  the  Command.Tx  superblock 
(Figure  34).  This  variable  is  passed  through  a  quantizer,  (block  17),  that  rounds  the 
variable  off  and  then  is  output  as  the  elev_cmd_usec  variable  which  is  displayed  in 
the  PW(usec)  column.  This  procedure  is  repeated  for  0  and  +5  degrees.  Once  these 
steps  are  completed  for  the  elevator  calibration,  they  must  be  repeated  for  the  other 
two  control  surfaces. 

To  calibrate  the  throttle  only  two  settings  must  be  entered.  First  move  the 
throttle  joystick  to  100%.  Read  the  PWM  signal  from  column  two  and  enter  it  into 
the  throt_pwm_100%  box.  Then  repeat  the  procedure  for  0%.  The  throttle  PWM 
signal  also  comes  from  the  PWM  IP_module.  It  is  assigned  the  variable  name  tpl3  , 
which  is  input  15  in  the  CommandJTx  superblock  (Figure  34).  This  variable  is  passed 


through  a  quantizer,  (block  17),  that  rounds  the  variable  off  and  then  is  output  as 
the  trt_cind_usec  variable  which  is  displayed  in  the  PW(usec)  column. 

The  data  in  Table  IV  was  collected  during  flight  test  and  represents  initial 
estimates  of  the  PWM  signals  for  the  elevator,  aileron,  rudder  and  throttle.  This 
data  is  for  the  UAV  Bluebird  and  will  require  recalculation  for  a  different  aircraft. 

Table  IV.  Calibrate  Command  Receiver  Data 


Actuator 

-5 

center 

+5 

Elevator 

1270 

1398 

1550 

Aileron 

1564 

1434 

1292 

Rudder 

1702 

1574 

1438 

- 

0% 

100% 

- 

Throttle 

1794 

r  1164 

- 

Once  the  data  has  been  entered  press  the  Return  button  to  return  to  the 
Master  display. 

3.  Calibrate  DAC 

This  screen  is  used  to  calibrate  the  DAC  signals.  The  flow  of  variables  for  this 
calibration  is  given  in  Figure  17. 

A  picture  of  this  screen  is  given  in  Figure  18.  There  are  numerous  variables  as¬ 
sociated  with  this  screen  and  they  are  listed  in  Chapter  V  under  the  calibrate_rf_uplink 
superblock.  The  calibration  for  the  three  control  surfaces  and  the  throttle  are  the 
same,  so  only  the  elevator  will  be  explained  in  detail. 

To  calibrate  the  elevator,  first  flip  the  Cal  Mode  switch  to  the  on  position. 
Then  move  the  elevator  joystick  on  the  command  transmitter  until  0  degrees  is  dis¬ 
played  in  the  Servoimu  and  PWM_deg  column.  This  column  displays  the  elev  jervo_deg 
variable  from  the  A  J)  JMU  superblock  and  the  elev_cmd_tx  variable  from  the  Com- 
mand.Tx  superblock  respectively.  Read  the  voltage  off  the  dial  to  the  left  of  this 
column  which  displays  the  voltage  from  the  DAC  IP_module  and  enter  it  into  the 
v_Odeg  box  to  the  right  of  the  column.  Once  this  value  has  been  entered,  vary  the 
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Figure  17.  Variable  Flow  for  DAC  Calibration 

voltage  on  the  dial  to  2.7  volts  (by  highlighting  the  number  and  entering  2.7)  and 
enter  the  degrees  from  the  center  column  into  the  deg_2.7v  box.  Repeat  this  pro¬ 
cedure  for  2.4  volts.  To  calibrate  the  other  two  surfaces  and  the  throttle,  repeat  the 
same  procedure. 

The  data  in  Table  V  Wcis  collected  from  test  flights  and  represents  initial 
estimates  for  the  DAC  Calibration.  Once  again  these  values  are  for  Bluebird  and 
require  recalculation  for  another  aircraft. 


Table  V.  Calibrate  DAC  Calibration  Data 


Actuator 

2.7 

0 

2.4 

Elevator 

-8.2 

2.37 

0.89 

Aileron 

-9.35 

2.35 

-1.3 

Rudder 

5.57 

2.52 

-3.52 

Throttle 

0.66 

2.25 

0.21 

Once  the  data  has  been  entered  press  the  Return  button  to  return  to  the 
previous  display. 
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Figure  18.  Calibrate  DAC  Screen 


4.  Cal  Air  Data 

This  screen  calibrates  the  four  air  data  sensors:  alpha,  beta,  velocity(vt),  and 
altitude.  A  figure  of  this  screen  is  given  in  Figure  19.  The  variables  associated  with 
this  screen  are  connected  to  the  AJ) JMU  superblock  which  is  explained  in  detail 
in  Chapter  V.  Since  the  IMU  has  only  a  five  word  capacity  for  data  transmission 
these  calibrations  are  not  connected.  The  equations  for  the  sensors  are  located  in 
the  AJD JMU  superblock  and  can  be  connected  after  calibrating  the  actuators.  To 
receive  this  data  from  the  aircraft  wires  connecting  the  actuators  to  the  pins  must  be 
switched  to  the  air  data  sensors. 

D»  DATA  DISPLAYS 

The  three  buttons  located  on  the  right  of  the  Master  lA  screen  (Figure  11) 
connect  the  user  to  addition  screens  that  give  data  on  the  IMU,  GPS,  and  Flight.  A 
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short  description  of  these  displays  is  given  below. 

1.  IMU  Master 

This  screen  displays  information  concerning  IMU  data.  See  Figure  20.  The 
IMU  screen  displays  information  for  the  nine  states  coming  from  the  IMU:  ax,ay,az,p,q,r,phi,theta, 
psi.  In  addition  to  the  states  the  five  words  being  sent  from  the  IMU  to  the  controller 
are  also  displayed.  Currently  these  five  words  are  assigned  to:  elevator,  aileron,  rud¬ 
der,  and  throttle  voltages.  The  fifth  word  is  not  connected.  These  words  can  be 
changed  by  connecting  the  wires  from  the  different  sensors  to  the  five  pins  located  on 
Bluebird.  The  variables  associated  with  this  screen  are  connected  to  the  imuJogic 
superblock  located  one  level  down  from  the  Sensor  calibrationJDisplay  superblock. 
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2.  GPS  Master 

The  GPS  screen  displays  information  relating  to  the  differential  GPS  system 
loaded  on  Bluebird.  There  is  one  receiver  and  antenna  located  on  Bluebird  and  the 
second  receiver  and  antenna  are  located  at  the  ground  station.  This  screen  provides 
information  from  the  GPS  receiver  such  as,  latitude,  longitude,  velocity,  heading,  and 
a  comparison  of  GPS  height  and  pressure  altitude.  See  Figure  21. 

There  are  also  two  other  GPS  lA  screens  that  provide  information  on  differ¬ 
ential  GPS  operation  and  Earth  Centered  Earth  Fixed(ECEF)  data.  See  Figures  22 
and  23.  The  variables  associated  with  these  screens  are  connected  to  the  gps  su¬ 
perblock  located  one  level  down  from  the  Sensor  calibrationJDisplay  superblock. 

3.  Flight  Display 

This  screen  is  the  main  flight  test  page.  See  Figure  24.  This  screen  contains 
switches,  dials  and  displays  to  monitor  flight  test  data.  It  is  divided  into  five  main 
sections,  each  concerning  a  certain  set  of  data  or  switchology.  The  first  section  in 
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Figure  21.  GPS  Master  lA  Screen 


the  upper  left  corner  contains  the  following  three  switches  to  toggle  among:  an  open 
or  closed  loop  controller,  external  comands,  and  Hardware-in- the-Loop  testing.  The 
next  section  displays  the  actuator  commands  for  each  actuator.  The  variables  asso¬ 
ciated  with  the  displayed  numbers  come  from  the  ControLblock,  Command.Tx  and 
AJDJMU  superblocks.  The  States  section  gives  either  IMU  data  or  model  states 
depending  on  the  selection  of  the  Display /Use  switch  located  below  the  display.  The 
Commands  section  compares  the  gauge  reading  from  the  aircraft  to  what  the  com¬ 
puter  is  commanding  for  aircraft  altitude,  airspeed  or  bank  angle.  The  three  windows 
in  the  center  allow  the  test  engineer  to  increase  altitude,  airspeed  or  bank  angle  in 
increments  by  depressing  the  arrows. 

E.  ACTUAL  FLIGHT  TEST 

The  flight  test  is  commenced  by  pressing  the  START  CONTROLLER  but¬ 
ton  on  the  iaclient  window  with  the  left  mouse  button  (Figure  12).  This  starts  the 


40 


^  st;«‘t±ozi  <ZB3 

ClianrMi  # 

Sat«llit»  « 

Ps«udorang*  correction  <m>  Paoudorango  rata  correction  (m/sec) 

Eptiecnerls  # 

1 

0 

0.00 

0.000 

O 

2 

0 

0.00 

0.000 

O 

3 

0 

0.00 

0.000 

o 

4 

0 

0.00 

0.000 

0 

5 

0 

0.00 

0.000 

0 

6 

0 

0.00 

0.000 

o 

GPS  tlm*  rmf.  <sm:> 

GPS  dteoksum 

0.0 

To  o  o  V*o^o  O  O  1 

Myohedcaum 

1  K*Rt:xum  1 

loop  o”o  pool 

Figure  22.  Differential  GPS  lA  Screen 


controller  and  model.  If  data  is  to  be  collected  the  data  parameters  must  be  entered 
by  first  depressing  the  DATA  PARAMiETERS  button.  This  gives  a  screen  similar 
to  the  HCE  and  by  turning  on  or  off  the  variables,  data  in  collected.  See  Figure  25. 

Once  the  parameters  have  been  set,  click  on  the  DATA  ACQUISITION 
button  and  data  collection  commences.  At  this  point  the  RC  pilot  taxies  the  aircraft 
and  takes  off.  Once  the  aircraft  is  established  in  a  cruise  configuration,  control  is 
handed  off  to  the  computer  controller  by  turning  on  the  computer’s  transmitter  and 
turning  off  the  RC  pilot’s  transmitter.  If  there  is  a  problem  with  the  controller,  control 
can  be  returned  to  the  RC  pilot  by  reversing  this  process.  Data  is  collected  until  the 
DATA  ACQUISITION  is  again  depressed.  This  must  be  accomplished  before  the 
contoller  is  stopped  or  data  will  be  lost.  At  the  termination  of  the  flight  the  RC  pilot 
lands  the  aircraft  and  the  controller  is  stopped. 
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Figure  23.  ECEF  GPS  lA  Screen 


F.  DATA  ANALYSIS 

A  series  of  flight  tests  were  conducted  using  the  unmanned  air  vehicle  Bluebird 
to  validate  the  calibration  equations  and  the  capability  of  the  RF  uplinks/ downlinks. 
Data  was  collected  using  the  data  acqusition  procedure  described  in  Chapter  IV.  Once 
the  Stop  Data  Acquisition  is  pressed  the  data  is  saved  in  a  file  using  the  model 
name  followed  by  a  .raw  extension.  This  data  must  be  converted  to  a  format  that 
can  be  used  by  Xmath.  This  is  done  by  depressing  the  Convert  DA  Data  button 
on  the  RealSim  GUI  (Figure  4).  When  the  conversion  is  complete  the  data  files  will 
have  a  .dat  extension. 

1.  Test  Data 

The  data  collected  for  the  Bluebird  test  showed  a  0.2  sec  delay  from  the  time 
the  control  input  was  sent  from  the  computer  to  the  time  it  reached  an  actuator. 
This  delay  is  shown  in  Figure  26  for  the  elevator  actuator. 

The  flight  test  data  plotted  is  for  the  variables  dacl.volt,  tp7  and  word2_imu. 
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Figure  24.  Master  Flight  Test  lA  Screen 


These  three  variables  measure  commanded  DAC  voltage  sent  to  the  transmitter,  the 
PWM  signal  received  by  the  ground  station,  and  the  voltage  measured  at  the  actuator 
pot.  This  data  has  been  normalized  for  ease  of  comparison.  Studying  the  graph,  one 
can  see  that  a  0.1  second  delay  occurs  from  the  time  the  voltage  is  sent  from  the 
DAC  to  the  tramnsmitter  and  a  second  0.1  second  delay  occurs  from  the  time  time 
the  transmitter  sends  the  PWM  signal  until  the  actuator  registers  a  movement.  The 
cause  of  this  delay  is  most  likely  due  to  the  time  it  takes  the  Futaba  Transmitter  to 
convert  a  voltage  to  a  PCM  signal  on  the  groimd,  and  for  the  the  Futaba  receiver  to 
convert  the  PWM  signal  into  an  actuator  command. 
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Figure  25.  Data  Acquisition  Screen 
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Figure  26.  Control  Delay  for  Elevator  Actuator 
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V.  IMPLEMENTATION 


A.  BACKGROUND 

Numerous  attempts  were  made  to  develop  a  universal  outer  shell  using  the 
hardware  and  software  explained  in  the  previous  chapter.  Problems  arose  when  the 
number  of  inputs/outputs  changed,  additional  switches  were  needed,  or  additional 
monitor  commands  were  needed  to  expand  the  model.  Therefore  a  universal  outer 
shell  was  developed  which  is  capable  of  growth  and  expansion.  This  outer  shell  is 
shown  in  Figure  27. 


Figure  27.  OuterShell 
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This  shell  has  the  capability  to  handle  250  inputs  and  350  outputs.  The  inputs 
and  outputs  are  divided  among  the  IP_modules  and  monitor  commands  which  are 
given  in  Table  VI.  Currently  only  the  input/output  variables  needed  are  connected. 
This  saves  time  in  the  compiling  process  and  keeps  the  variables  in  a  logical  order. 

Table  VI.  Input/Output  Configuration 


Outputs 

16  A/D 

16  D/A 

10  PWM 

10  PWM 

60  Serial  A 

60  Serial  A 

lliaiKsapi:! 

60  Serial  B 

20  Switch 

- 

180  Monitor 

These  inputs/outputs  are  connected  to  the  Process.!  superblock,  which  con¬ 
tains  four  additional  superblocks:  Sensor  ClibrationJDisplay,  Controllblbck, 
Sensor  Filtering,  and  calibrate  j-f.uplink.  Each  of  these  blocks  performs  a  spe¬ 
cific  function  and  each  will  be  explained  in  the  following  sections.  See  Figure  28. 

One  of  the  nice  features  of  this  structure  is  its  flexibility.  If  the  engineer  designs 
a  new  controller  for  the  aircraft  all  he  has  to  do  is  disconnect  the  old  controller  and 
connect  the  new  controller.  This  usually  involves  only  a  few  mouse  clicks.  Then  using 
a  pull-down  menu  in  SystemBuild,  real  time  code  is  generated  and  using  AutoCode 
the  C  code  to  drive  the  hardware  is  produced.  This  whole  process  can  be  accomplished 
in  a  matter  of  minutes,  where  it  used  to  take  months  for  a  group  of  programmers  to 
develop  the  C  code  for  the  hardware  before  testing  can  be  accomplished. 

B.  SENSOR  CALIBRATION JDISPLAY 

It  is  necessary  to  calibrate  the  actuators  and  sensors  on  Bluebird  in  order  to 
obtain  accurate  readings  for  the  controller  and  to  place  the  signals  in  the  proper 
format.  The  actuator  pick-offs  on  Bluebird  use  voltages  to  sense  control  surface 
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Figure  28.  Process.l  SuperBlock 

motion.  Therefore  a  mapping  was  needed  to  match  a  certain  voltage  to  a  control 
surface  deflection  in  degrees.  To  obtain  a  calibration  the  following  steps  must  be 
accomplished. 

•  Using  a  voltmeter  and  a  protractor  measure  the  control  deflection  vs.  voltage 
data. 

•  Plot  this  data  and  obtain  equations  for  the  slopes  of  the  lines. 

•  Type  equations  into  the  appropiate  superblocks. 

•  Fly  the  aircraft  and  obtain  trim  settings. 

•  Type  these  trim  settings  into  the  Cal  Actuators,  Cal  Com  Rec,  Calibrate  DAC 
and  Cal  Air  Data  lA  screens. 
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Data  was  collected  for  the  elevator,  rudder  and  aileron,  which  was  then  plotted 
using  Matlab.  See  Figures  29,  30,  and  31. 


Figure  29.  Aileron  Calibration 


Figure  30.  Elevator  Calibration 
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The  data  was  interpolated  using  a  least  squares  fit  method  to  obtain  a  linear 
approximation  that  could  be  used  in  the  model.  The  linear  approximation  was  chosen 
so  the  data  could  later  be  scaled  for  trim  settings  in  flight.  If  a  non-linear  curve  fit 
was  used  every  time  the  trim  settings  were  changed  a  new  set  of  curves  would  be 
required.  Using  a  linear  fit  a  new  trim  setting  will  simply  shift  the  curve  up  or  down 
along  the  y-axis. 

All  the  sensor  and  actuator  calibrations  are  located  in  the  Sensor  Calibra- 
tionJDisplay  SuperBlock  .  Located  in  this  superblock  are  the  calibrations  for  the 
GPS,  IMU  logic,  Command  receiver,  and  air  data  sensors  (see  Figure  32). 

By  opening  these  superblocks  the  equations  calculated  by  the  calibration  pro¬ 
cess  are  entered  into  algebraic  blocks.  For  example,  once  the  equations  are  calculated 
for  the  actuators  they  are  entered  into  the  A_D_IMU  SuperBlock  located  two  levels 
down  from  the  Sensor  Calibration  JDisplay  SuperBlock.  This  is  reached  by  double 
clicking  on  the  number  in  the  upper  right  corner  of  the  Sensor  Calibration  JDisplay 
SuperBlock  and  repeating  the  procedure  on  the  A_D  JEMU  SuperBlock.  A  brief  de- 
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Figure  32.  Sensor  CalibrationJDisplay  Superblock 

scription  of  the  A_D  JMU  superblock  and  the  CommandJTx  superblock  are  given 
next. 

1.  A_DJMU  Superblock 

The  A_D_IMU  Superblock  is  used  to  calibrate  the  four  actuator  pots  and  air 
data  sensors.  See  Figure  33. 

The  superblock  has  20  input  and  10  output  variables  and  these  are  given  in 
Table  VII.  Currently,  only  the  first  14  inputs  have  variable  names  assigned.  The 
remaining  six  inputs  are  intended  for  growth. 

The  calibration  equations  given  in  Figures  29,  30,  and  31  are  entered  into 
block  number  2  which  is  an  algebraic  block.  The  input  variables  in  this  block  are 
the  four  IMU  words,  in  volts,  and  the  output  variables  are  these  inputs  converted  to 
degrees.  These  outputs  are  then  sent  through  a  switch  and  into  a  summer.  At  the 
summer,  the  trim  values  entered  in  the  Actuator  Calibration  lA  screen,  (Figure  14), 
are  added,  and  then  the  values  are  output  to  the  Sensor-Calibration  superblock. 

The  top  half  of  the  A_DJ[MU  superblock  is  for  the  calibration  of  the  air  data 
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Figure  33.  A_DJ[MU  Superblock 

sensors.  This  section  is  not  connected  due  to  the  limitations  of  the  IMU  which  only 
allows  five  words  to  be  transmitted  to  the  ground  station. 

2.  Command.Tx  Superblock 

The  CommandJTx  superblock  is  used  in  conjuction  with  the  AJDJMU  su¬ 
perblock  for  actuator  calibrations.  This  block  has  45  input  and  16  output  variables. 
See  Figure  34.  Inputs  4,  8,  12,  and  15  are  the  four  PWM  signals  for  the  elevator, 
aileron,  rudder,  and  throttle  respectively.  These  four  variables  are  input  into  a  quan¬ 
tizer  which  rounds  off  the  values.  The  variables  are  then  output  to  two  locations:  the 
Calibrate  Command  Recevier  lA  screen  (see  explaination  in  Chapter  IVchap5.tex) 
and  the  elevator,  aileron,  rudder  and  throttle  shift  blocks. 

The  shift  blocks  take  the  PWM  values  from  the  receiver  and  subtract  off  the 
PWM  value  for  the  center  location  of  the  joystick.  This  is  necessary  to  put  the  PWM 
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Table  VII.  AJDJMU  Input /output  Variables 


Input  name 

Output  name 

1 

wordlJmu 

2 

word2Jmu 

3 

word3Jmu 

elev_servo_deg 

4 

word4Jmu 

rudjservo-deg 

5 

wordSJmu 

ail_servo_deg 

6 

imujservojsw 

trtjservo-deg 

7 

elev-servo-trim 

alphaJmu-deg 

8 

rud_servo_trim 

betaimu-deg 

9 

ail-servo-trim 

vtJmu-fps 

10 

trt_servo_trim 

alt  imu-ft 

11 

alphaJmuJtrim 

betaJmu-trim 

HHHI 

13 

vtJmu-trim 

14 

altJmu-trim 

- 

signals  in  the  proper  format  for  the  scaler  blocks.  The  scaler  blocks  take  the  PWM 
signals  in  microseconds  and  convert  them  to  degrees.  In  addition  to  the  shifted  PWM 
signal,  the  scaler  blocks  also  has  inputs  for  the  PWM  max  up,  PWM  max  down 
variables  in  microseconds  and  full  scale  deflection  variable  in  degrees.  The  values 
for  these  inputs  are  obtained  from  the  Calibrate  Command  Receiver  lA  screen  and 
are  used  in  a  formula  developed  in  [Ref.  8]  to  convert  PWM  juseconds  into  degrees. 
After  leaving  the  scaler  blocks  the  PWM  signals,  now  converted  to  degrees,  are  added 
to  the  trim  values  from  the  Actuator  Calibration  lA  screen.  These  variables  are  then 
output  to  the  Sensor-Calibration  superblock. 

The  last  two  sets  of  blocks  labelled  channels  and  channels  are  used  for  the  flap 
and  nose  wheel  steering.  These  will  be  used  when  the  aircraft  is  fully  autonomous, 
i.e.  computer  controlled  from  takeoff  to  landing. 
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Figure  34.  CommandJTx  Superblock 

C.  CALIBRATE_RF_UPLINK 

This  superblock  calibrates  the  command  transmitter  for  the  RF  uplink  to 
the  aircraft.  These  calibrations  are  similar  operations  that  are  performed  by  the 
Sensor  Calibration JDisplay  superblock,  except  in  the  reverse  order.  It  takes  controller 
outputs,  in  degrees,  and  converts  them  to  DAC  voltages  to  be  transmitted  to  Bluebird 
via  an  RF  link.  This  superblock  has  56  input  and  23  output  variables  which  are  tied 
to  the  Calibrate  DAC  lA  screen.  (See  Chapter  IV  for  a  complete  explanation  of  this 
screen.)  Expanding  the  Calibrate jrLuplink  superblock  gives  a  new  set  of  blocks  which 
are  described  in  Figure  35). 

The  first  input  to  the  degrees  to  DAC  voltage  algebraic  blocks  comes  from 
the  Control-block  superblock  and  the  remaining  three  inputs  come  from  the  Calibrate 
DAC  lA  screen.  These  inputs  are  used  in  an  equation  that  converts  degrees  to  DAC 
voltage.  Once  the  variables  are  converted  to  degrees  they  are  sent  into  a  switch  which 
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Figure  35.  Expanded  Calibrate_rf_uplink  Superblock 

is  connected  to  tbe  Calibrate  DAC  lA  screen.  If  the  switch  is  on  the  calibration  mode 
is  activated,  the  calibration  data  is  displayed  on  the  screen.  If  the  switch  is  off  the 
DAC  voltages  are  passed  through  the  switch  into  a  DAC  limiter  that  limits  the  DAC 
voltage  to  5  volts.  From  this  block  the  DAC  voltages  are  outputed  to  the  DAC 
superblock,  which  in  turn  sends  them  to  the  DAC  IP  .module. 

D.  CONTROL_BLOCK 

This  SuperBlock  contains  the  controller,  dynamics  and  kinematics  for  Blue¬ 
bird.  The  equations  that  were  derived  in  Chapter  II  are  symbolically  displayed 
in  this  superblock.  Inputs  are  fed  from  the  Sensor  Calibration JDisplay  superblock. 
Sensor  Filtering  superblock,  and  the  Monitor  Commands  and  Monitor  Switches  su¬ 
perblocks  located  in  the  outer  shell  to  this  superblock.  Outputs  are  fed  to  the  Cali- 
bratenrLuplink,  where  the  outputs  are  converted  back  to  DAC  voltages  for  RF  trans- 
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Figure  36.  Expanded  Control-block  Superblock 

mission  to  Bluebird,  and  the  Sensor  Filtering  superblock  where  the  signals  are  filtered. 

Expanding  the  ControLblock  a  new  set  of  superblocks  is  given  (see  Figure 
36). 

Looking  at  Figure  36,  some  Superblocks  and  blocks  of  interest  are: 

•  bbird  -  this  superblock  contains  the  EOM  of  Bluebird. 

•  delta  controller  -  this  superblock  contains  the  delta  controller  developed  to 
fly  Bluebird  in  cruise  flight. 

•  command  hold  -  this  block  holds  the  RC  pilot’s  last  commands  until  control 
is  handed  over  to  the  computer. 

The  remaining  blocks,  96,  97,  98,  99,  14,  6,  and  7  perform  functions  such  as 
conversions  and  monitor  command  switchology  used  for  flight  test.  A  complete  listing 
of  the  superblocks  are  given  in  the  Appendix. 
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Figure  37.  Expanded  Sensor  Filtering  Superblock 

E.  SENSOR  FILTERING 

This  superblock  contains  various  filters  needed  for  the  controller.  Inputs  are 
fed  from  the  Sensor  CalibrationJDisplay  superblock,  Control-block  superblock,  and 
the  Monitor  Commands  and  Monitor  Switches  superblocks  located  in  the  outer  shell. 
The  filtered  outputs  are  fed  to  the  ContoLblock. 

Expanding  the  Sensor  Filtering  superblock  a  new  set  of  superblocks  are 
given  (see  Figure  37). 

Looking  at  Figure  37,  some  Superblocks  and  blocks  of  interest  are: 

•  gyro_angleJfilters  -  this  superblock  contains  kahnan  filters  that  damp  out 
the  vibrations  in  the  IMU. 

•  alt_vtJBlter  -  this  superblock  contains  filters  to  correct  for  errors  in  the  pitot 
static  system. 
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•  incremental  commands  -  this  superblock  contains  rate  limiters  for  altitude, 
airspeed  and  phi. 

A  complete  listing  of  the  superblocks  are  given  in  the  Appendix. 
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VI.  CONCLUSIONS  AND 
RECOMMENDATIONS 

A.  CONCLUSIONS 

The  MATRIXA-Product  Family  of  hardware/software  developed  by  Integrated 
System  Inc.(ISI)  is  an  excellent  tool  for  the  design,  test  and  implementation  of  con¬ 
trollers.  By  stepping  the  engineer  through  the  rapid  prototyping  design  process  the 
time  required  to  implement  a  design  concept  is  significantly  reduced.  Where  it  used 
to  take  years  to  develop  a  working  prototype  from  a  initial  design  concept,  by  using 
ISI’s  product  the  time  is  reduced  to  months. 

One  of  the  great  benefits  of  this  product  is  the  ability  to  automatically  pro¬ 
gram  in  a  higher  order  language  code  such  as  C.  This  eliminates  the  necessity  of 
having  dedicated  software  programmers  to  develop  code  for  a  working  model.  This 
is  especially  true  when  changes  are  made  in  the  controller  and  new  code  must  to  be 
generated.  Now,  the  10,000  lines  of  C  code  are  generated  in  minutes. 

Another  benefit  of  this  product  is  the  ability  to  collect  and  analyze  data  during 
the  flight  testing  process.  During  flight  test  we  were  able  to  make  changes  in  the  field 
without  having  to  dismantle  the  entire  setup  and  transporting  it  back  to  the  lab. 
Using  the  data  acquisition  editor  and  Xmath,  graphs  were  produced  to  analyze  the 
success  of  the  controller  and  filter  designs.  With  a  conventional  test  setup  this  would 
not  have  been  possible. 

The  outershell  developed  in  SystemBuild  greatly  increases  the  understanding 
and  tracking  of  the  model  variables.  Prior  to  this  setup  every  time  the  model  was 
changed  or  variables  added  the  outer  connections  had  to  be  modified.  Now,  using  the 
outershell  with  its  built  in  growth  capability,  it  is  easy  to  add  variables  and  monitor 
commands. 
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B.  RECOMMENDATIONS 


Based  on  tlie  conclusions  presented  above  and  the  experience  of  developing  the 
uniform  system  presented  in  this  thesis,  the  following  recommendations  are  forwarded. 


•  Test  the  uniform  system  with  another  aircraft  model.  Due  to  time  constraints 
and  aircraft  availability,  Bluebird  was  the  only  UAV  that  was  tested  using  the 
system.  Another  UAV,  called  the  FROG,  is  being  set  up  for  testing  and  could 
be  used  for  this  purpose. 

•  Provide  a  realtime  animation  of  the  test  aircraft  in  flight.  When  flight  test 
are  being  conducted  it  is  very  difficult  to  see  the  aircraft  due  to  its  small  size. 
Using  a  3D  simulation,  such  as  that  provided  by  Designer’s  Workbench,  would 
give  the  test  engineer  the  ability  to  better  monitor  the  aircraft’s  flight.  This 
will  involve  significant  expertise  in  C  programming  and  TCP/IP  networking. 

•  Purchase  a  portable  Unix  based  workstation.  Currently  it  is  necessary  to 
transport  a  full  size  Sun  workstation  to  the  test  site.  This  is  difficult  due  to 
the  large  size  and  sensitivity  of  the  hardware.  We  have  already  burnt  out  a 
monitor  and  frayed  a  SCSI  cable  during  the  transport  process. 
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APPENDIX.  ADDITIONAL  SYSTEMBUILD 

DIAGRAMS 


15-SEP-96 

Discrete  SuperBlodc  Sample  Period  Sample  Skew  Inputs  Outputs  En^Ie  Signal 

bbird  0.005  0.  7  24  Parent 


initial  condition 


Figure  38.  bbird 
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15-SEP-96 

DisCTeteSuperBIod  Sample  Period  Sample  Skew  Inputs  Ou^uts  Enable  Signal 
Int^rators _ O.QOS _ ^0.  24  12  Parent 


Figure  39.  Integrators 
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15-SEP-96 


Discrete  SuperBlock  Sample  Period  Sample  Skew  Inputs  Ou^uts  Enable  Signal 
Dynamics,Euler  0.005  0,005  31  15  Parent 


Figure  40.  DynamicsJEuler 


15-SEP-96 


Discrete  SuperBlock  Sample  Period  Sample  Skew  Inputs  Outputs  Enable  Signal 
aero  forces  and  moments  0.005  0.005  22  10  ftirent 


Figure  41.  ciero_forces_and._inoments 
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15^-96 


Figure  42.  lin_velocity_eq 
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15^EP.96 

Discrete  SuperBlock  Sample  Period  Sample  Skew  Inputs  Outputs  Enable  Signal 

LJot_eq  0.005  0.005  5  3  Parent 


Figure  43.  L_dot_eq 
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15-SEP.96 


Discrete  SuperBlod  Sample  Period  Sample  Skew  Inputs  Ou^uts  Enable  Signal 
nonlinear  Ctrl  0.005  0.  4  4  Parent 


Figure  44.  nonlinear^ctrl 
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Discrete  SuperBlodc  Sample  Period  Sample  Skew  Inputs  Outputs  Enable  Signal 

command  hold  0.04  0.  7  4  I^ent 


15-SEP-96 

Discrete  SuperBlock  Sample  Period  Sample  Skew  Inputs  Outouts  Enable  Signal 
delta  controller _ 0.04  0.005  21  15  Parent 


Figure  46.  delta-controller 
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15^-96 

DiscideSifierBlock  Period  SanapkSb^  Inputs  OolpaU  Enable  Signal 

delta  intcgratoc _ OM _ QjQQS  15  4  Parent 


Figure  47.  deltaJntegrator 
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Figure  48.  act_model 
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15-SEP-96 

Discrete  SupcrBlock  Sample  Fenod  San^leSi^  fcputT'OaJote  Enable  Signal 
Sensor  Hltering _ 0^04 _ 0 _ 40  30  Parent 


Figure  49.  Sensor-Filtering 
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15-SEP-96 

Discrete SoperBlock  Sanple Period  Sample lopats  Oo^ats  En^bieSieni 
alt_vt,filter _ 004 _ 0  10  6  Parent 


Figure  51.  alt_vt -filter 
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15-SEP-96 


Disaete  SaperBlodc  Sample  Pedod  San^leSl^w  Inputs  On^nts  Enable  Siena! 
convert _ 0.04  0.  20  20  Parent 


Figure  52.  convert 


15-SEP-96 

Discrete  SapcrBlock  Sarq>le  Poiod  San^leSkew  Inputs  C)a4)uts  Enable  Signal 
incremental  commands  0.04  0.  3  3  Parent 


rate  limit 


Figure  53.  incrementaLcommands 
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Discrete  SoperBlock  Sample  Period  SangjleSkew  fiipats  Gamuts  Enable  Sima! 
calibrate,rf_npUDlc _ 0£4 _ O _ 56  23  Parent 
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